Pre-encoded H.265: length-prefixed ingest, pacer tuning, leaner publish path - #1579

Hardware encoder bridges can often emit H.265 as 4-byte length-prefixed NAL units (hev1), which the Rust SDK could not publish pre-encoded. Once publishing worked, these tracks also sat in the pacer for seconds after publishing, and the publish path did redundant work on every frame. This PR fixes all three, one commit per stage, each with its own changeset:

1. Publish length-prefixed pre-encoded H.265

• livekit-capture: LengthPrefixedAccessUnitParser (previously test-only, H.264 only) handles H.264 and H.265, with an opt-in single-slice flush that completes a picture as soon as its slice arrives instead of a frame later. Adds access_unit_from_h265_hvcc, hev1 caps in the GStreamer source, and frame_metadata_from_sei for the LKTS packet-trailer SEI (the Go SDK's ReaderTrackWithPacketTrailer convention).
• livekit: single-layer video tracks announce their codec in simulcast_codecs, as the Go SDK does.
• local_video: new encoded_publisher example that publishes a length-prefixed stream received over TCP.

2. Let pre-encoded tracks leave the pacer promptly
A pre-encoded stream arrives at its encoder's bitrate, but the starting estimate is capped at 1 Mbps, so packets queued in the pacer for ~8 s after publishing (~510 ms per packet at the peak for 1080p30 at 4 Mbps).

• webrtc-sys: read field trials from LIVEKIT_WEBRTC_FIELD_TRIALS. With WebRTC-Video-Pacing/factor:10/ the startup delay drops to ~4 ms, then ~0.
• livekit: pre-encoded tracks are exempt from the starting-estimate cap, like screen share (peak ~510 ms → ~210–440 ms on its own).
• encoded_publisher --stats logs codec, frames sent and pacer delay from standard WebRTC stats.

3. Trim the publish path

• The length-prefixed parser copied each access unit twice and rescanned it byte by byte; it now converts in place and classifies from known NAL ranges: 321 µs → 3.4 µs per 1080p access unit. find_start_code also skips between 0x01 bytes, which speeds up every Annex-B path (an exhaustive test pins it to the old behaviour).
• Pre-encoded video is published as a single layer. FFI clients such as the C++ SDK leave simulcast on by default; the pass-through then announced 360p/180p layers carrying copies of the full stream and requested a keyframe on almost every frame (352 requests in 15 s, vs 28 after).

Testing

• cargo test -p livekit-capture --features source-gstreamer (55 pass), cargo test -p livekit --lib, cargo test -p webrtc-sys --lib.
• Manual: gst-launch-1.0 videotestsrc ! nvcudah265enc ! h265parse config-interval=-1 ! video/x-h265,stream-format=hev1,alignment=au ! tcpserversink into encoded_publisher --single-slice-flush --stats against livekit-server --dev. Cross-checked end to end with a packet capture and a subscriber: steady-state publish latency p50 0.84 ms (Go SDK: 0.49 ms).
• Also verified with a GStreamer camera pipeline that sends length-prefixed H.265 with SEI timestamp metadata over TCP, published with --single-slice-flush --packet-trailer to livekit-server --dev and LiveKit Cloud; the subscriber received 720p30 with the user timestamp and frame ID intact.

Notes

• Tested on Linux with NVENC/NVDEC and on macOS (Apple Silicon) with VideoToolbox. On a host without a local H.265 encoder, H.265 also needs jetson h265: encoder #1451 to be negotiable.

Created with Claude Opus 5.5 in Claude Code.